Subject: Comments on recent proposals

From: [email-masked] (Paul Brittain)
Date: Tue, 8 Feb 94 11:45:58 GMT

This mail has been sent to the general DLSw mailer because it affects several
siglets.  As many people subscribe to >1 siglet, I did not wish to subject
you all to several copies of the same note.  My apologies if

-       you are not interested in any of these siglets
-       you have not read the referenced proposals
-       my assumption that all siglet members are also on the general DLSw
        mailing list proves to be incorrect (can someone please let me
        know if this is the case).

And so to work....

Steve Klein, Peter Gayek and Choon Lee have recently posted various proposals
on the connect, flow-control and loop-prevention siglets respectively.  This
note presents my take on these proposals both separately and where they
interact - hence the wide mailing.  I have not included copies of these
proposals, however, since that would have produced a mailing running to
several thousand lines!

Areas of interaction are marked with asterisks in the left margin to make it
easier to pick them out so that you can have a chance to think about them
before the AIW.  I have also tried to list areas of interaction under my
headings for both affected siglets.

See you all in Anaheim next week,

Paul Brittain.
Data Connection Ltd
+44 244 313440

                   --------------------------------------

CONNECTION SIGLET - Steve Klein's proposals
===========================================

Steve,

Revised DLSw FSMs:
------------------

Thanks for the revised FSM tables.  These seem reasonable and complete.  I have
only a few of points as follows:

-       You documented that the receipt of an ICR in e.g. CIRCUIT_ESTABLISHED
        causes a HALT_DL_NO_ACK to be issued.  I assume this should also occur
        in the following additional states:

        -       CONTACT_PENDING
        -       RESTART_PENDING

        Depending on how a specific implementation associates an SSP message
        with a circuit, and how we resolve crossover cases, it may also want to
        behave in this way in CIRCUIT_PENDING, DISCONNECT_PENDING and
        HALT_PENDING states.

-       Similarly for NETBIOS_NR frames.

-       You have not documented the use of the TEST_CIRCUIT_REQ/RSP messages.

        My understanding is that these are used by the APPN implementation in
        the 6611.  I am not clear on whether you intend them to become part of
        the standard or whether they will remain 6611-specific messages.

        If they are to become part of the standard, we need to document how
        they are handled in each state (e.g. are they only valid in CONNECTED
        state?) and what their precise use is.  However if you do not propose
        them as part of the standard, how do we ensure that a 6611 will not
        send such messages to a 'standard' DLSw partner?

        I have no strong feeling either way for whether they should be in the
        standard or not provided they are clearly explained if we do include
        them.

-       INTERACTION WITH FLOW CONTROL:

*       You have documented the ENTER/EXIT_BUSY messages but Peter Gayek is
*       proposing that support for these messages is not mandatory to allow for
*       pre-standard DLSw implementations.  This needs to be made clear in a
*       note to the FSM tables.

        By the way, what frames are affected by the ENTER/EXIT_BUSY - I-frames
        only, I and UI frames or all frame types for the circuit including XID
        and SABME?  I had assumed these affected I-frames only (because of the
        DLC action they cause), but then can't understand why they can be
        issued in any state other than CONNECTED.

Revised Connect Flows:
----------------------

I like your CUR_ex/CUR_cs approach, in particular the backwards compatibility.
Just a couple of comments on the flows that you documented:

-       The first non-broadcast frame for a circuit could be a SABME instead of
        an XID.  However the same processing is equally valid in this case - it
        simply needs an additional note to this effect below the flows if they
        are incorporated into the revised RFC.

-       We have previously discussed on the connect siglet the case of a
        NETBIOS_NQ resolving to an existing circuit, which causes the NETBIOS
        NAME_RECOGNIZED message to flow back to the origin as a DGRMFRAME.

        With the advent of _ex messages, should we continue this?  My opinion
        is that we should, but the other obvious alternative is that
        NETBIOS_NQ_ex requests always receive a NETBIOS_NR_ex response, but
        NETBIOS_NQ_cs requests can be resolved in the current manner.

-       INTERACTION WITH LOOP PREVENTION:

*       I have not yet had time to think through how Choon Lee's proposal
*       interacts with these revised connection flows, but there are likely to
*       be some complications here.  We should discuss this in the AIW.
*
*       Note that the next point below assumes that we adopt something similar
*       to Choon's proposal, i.e. we have a state transition when a CUR is
*       sent so that a standard DLSw can be assumed to be aware of whether it
*       has issued a CUR.

-       We still need to resolve the crossover cases for connection setup
        between two DLSw partners.  Please comment on the proposal that
        is described below.  Assume for now that we are dealing with CUR_cs
        requests only.

        The basic mechanism is to detect a crossover of CURs and for both sides
        of the circuit to independently compare their IP address with that of
        the partner.  The partner with the lower IP address (in the same sense
        as Choon's loop prevention proposal) is the contention winner and
        ignores the CUR that crossed with its own connection setup attempt.
        The contention loser throws away all knowledge of the CUR that is has
        issued and continues as if it had only received the CUR from the
        contention winner (although an implementation could choose to retain
        any routing information for the DLC partner that it had already
        derived from the TEST exchange and hence issue the ICR immediately).

        This is relatively easy to implement if both partners are standard
        DLSw boxes, but let's look at the mixed case.

        A standard DLSw will be aware of whether it has issued a CUR for a
        circuit, and hence can detect a crossover before it requests the DLC to
        attempt to resolve the circuit.  In contrast a pre-standard DLSw is not
        (necessarily) aware of this situation and only sees the crossover when
        the ICRs cross.  We can use this difference to our advantage when
        implementing backwards compatibility.

        If a standard DLSw is aware (from the lack of cap-ex) that its partner
        is pre-standard, it should always adopt the role of contention loser
        regardless of the relative IP addresses.  This ensures that the circuit
        will always be resolved once only with the pre-standard DLSw as the
        origin DLSw.

        I am undecided about the best method to adopt for CUR_cs/CUR_ex or
        CUR_ex/CUR_ex crossover cases.  My current opinion is that any CUR_ex
        received by a standard DLSw should cause an ICR_ex response without any
        attempt to resolve crossover cases.  Since these are only explorer
        frames, such a system should be OK.

( Since writing the above, I have just seen your proposal on crossover
resolution.  We seem to have adopted a similar basic system, but use a
different mechanism for determining the contention winner (IP vs MAC address).
IP address has the advantage of being a once-per-partner determination rather
than a once-per-MAC/SAP pair calculation, but otherwise there is little
difference.  The mixed case of standard and pre-standard DLSw partners, and the
handling of CUR_ex crossover cases need to be considered for either solution.)

                 --------------------------------------

FLOW CONTROL - Peter Gayek's proposal
=====================================

Peter,

Thanks for resolving the patents issue.  I have looked at your revised proposal
and believe it is a sound approach.  You asked for comments on a number of
points:

-       Transport level flow control

        If we confirm that such a mechanism is desired in the standard, I
        believe that it should be subject to a separate cap-ex rather than
        merged with the FIXED/ADAPT options for circuit flow control.

-       I believe it is important that the RWI takes the window size down to
        zero instead of one.  A DLSw will only issue the RWI when it is
        chronically short of buffer space.  The last thing it wants to do in
        such a situation is grant all DLSw partners permission to send more
        frames.

-       INTERACTION WITH CONNECT:

*       I agree with your decision not to make ENTER/EXIT_BUSY mandatory, but
*       we need to ensure that the FSM tables in a revised RFC make this clear.
*       (see also the Connect siglet comments above).  However, like Shannon,
*       I'm not sure that this pacing mechanism is usable.

                 --------------------------------------

LOOP PREVENTION SIGLET - Choon Lee's Proposal
=============================================

Choon,

Thanks for your detailed proposal on loop prevention.  Taken in isolation, my
only real concern with it is the potential for slowing circuit setup, but
anything faster is going to need us to maintain distributed topology data -
no thanks!!

* A potential trouble area is the interactions between your proposal, Steve
* Klein's connect proposals and the circuit crossover resolution system I
* described above.  We will probably waste a lot of time trying to sort out all
* the possible cases by mail before getting to discuss each proposal at the
* AIW, so let's talk about it in Anaheim next week.

On a more detailed level, I have a few smaller issues:

-       Is there any semantic difference between your HALT_CIRCUIT message
        and the HALT_DL_NO_ACK message that already exists?  If not, let's
        stick with the HALT_DL_NO_ACK.

-       The new LOOP_RESOLVING state will need to handle the receipt of a
        DLC_RESOLVE_C request (a crossover case).  I don't think it will be
        good enough to simply issue an ICR in such cases.  We will need to pend
        any action on the DLC_RESOLVE_C until the DLC_LD messages have been
        exchanged and any loops (hopefully!) prevented.

-       For completeness, the revised RFC should include suggested handling for
        DLC_LD_* messages in all states.  For example it is possible, if
        unpleasant, for both K and M to reach RESOLVE_PENDING state before
        receiving each others DLC_LD_CMD (i.e. if both timeouts are set too
        low).  We then have a loop that has not been prevented so both DLSw
        should at least log this event!

*       One possible solution is to continue to handle LD messages according to
*       Loop Detection ID until the CIRCUIT_PENDING state is reached.
*       Alternatively, we could try to hang the LD processing off of Steve's
*       CUR_ex handling instead of the CUR_cs that I have assumed so far.  Then
*       the LD processing could continue until the ICR_ex is sent back, giving
*       considerably more time to resolve any loops.

                 --------------------------------------